#3 Kubernetes Pod, Service, Volume

Pod

파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유한다. 그 자원은 다음을 포함한다.

• 볼륨과 같은, 공유 스토리지
• 클러스터 IP 주소와 같은, 네트워킹
• 컨테이너 이미지 버전 또는 사용할 특정 포트와 같이, 각 컨테이너가 동작하는 방식에 대한 정보

파드는 쿠버네티스 플랫폼 상에서 최소 단위가 된다.

각 파드는 스케쥴 되어진 노드에게 묶여지게 된다. 그리고 (재구동 정책에 따라) 소멸되거나 삭제되기 전까지 그 노드에 유지된다. 노드에 실패가 발생할 경우, 클러스터 내에 가용한 다른 노드들을 대상으로 스케쥴되어진다.

1. Container

1. 하나의 독립적인 서비스를 구동할 수 있는 컨테이너들이 있다

   • 한 파드 안에서 여러개의 컨테이너를 생성할 수 있다.
2. 그 컨테이너는 각각의 컨테이너끼리 서비스를 연결할 수 있도록 포트를 가지고 있다.
3. 한 컨테이너에서 포트를 여러개 가질 순 있지만, 한 파드 안에서 컨테이너끼리 중복된 포트를 가질 수 없다.

4. 파드를 생성 시 IP가 생성되고, 쿠버네티스 클러스터로만 접근이 가능하다. 또한 재생성 시 변경된다.

   • 휘발성의 특징을 가지고 있는 이 IP는 외부에서 접근이 불가능하다.

2. Label(속성)

라벨 사용이유 : 목적에 따라 오브젝트들을 분류하고, 분류된 오브젝트들만 따로 골라서 연결하기 위해서이다.

• 모든 오브젝트에서 사용이 가능

2-1. Label의 구성

• key와 value 가 한쌍으로 이루어져 있다.

• 한 파드에는 여러개의 Label을 달 수 있다

  예시) 웹 파드만 service 오브젝트의 selector를 통해 운용하고 싶으면 라벨로 필터링할 수 있다. 즉, 자신이 원하는 파드만 골라서 할 수 있다. 마치 해쉬테이블처럼 검색해서 사용

3. Node Schedule

• 파드는 결국 여러 노드들 중에 한 노드에 올라가져야 한다. 그 중 2가지 방법이 존재

  1. 직접선택
  2. 자동할당(스케줄러가 판단)

직접 선택: 노드에 원하는 label를 달고 Pod.yml 파일에서 nodeSelector 정의를 통해 연결이 가능
자동할당: 노드에는 전체 사용가능한 자원량이 정해져있다. CPU와 Memory가 대표적이며, 스케줄러가 각 노드의 점수를 매겨 파드를 알아서 스케줄링 해준다. 또한 파드에는 resources 옵션으로 자원량을 한정 시킬 수 있다.

하나의 Pod 내에서 많은 자원을 소비하게 될 경우 같은 노드 안에 있는 다른 파드들은 자원을 공급받지 못해 같이 다운타임이 발생할 수 있으므로 필요에 따라 자원량을 한정하는 것이 좋다.

3-1. resources

• requests: 요청하는 자원의 량

• limits: 최대 허용 자원의 량

  • 예시

  resources:
  requests:
    memory: 2Gi  <!-- memory 자원 최소 요청의 량
    limits: 3Gi  <!-- memory 자원 최대 허용량

• limits의 옵션은 자원의 성격에 따라 동작하는 방식이 다르다.

  • memory는 초과시 파드를 종료 시킴
  • CPU 초과시 request까지 낮춤. 즉, over시 종료되지 않음

이렇게 서로 다른 이유는 자원의 성격이 다르기 때문

알고가야할 내용: Node

파드는 언제나 노드 상에서 동작한다. 노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있다. 각 노드는 마스터에 의해 관리된다. 하나의 노드는 여러 개의 파드를 가질 수 있고, 쿠버네티스 마스터는 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리한다.

Service

Service는 기본적으로 IP를 가지고 있다. 그리고 연결된 Pod에 한해서 이 IP를 통해 Pod에 접근이 가능하다.
하지만 Pod 자체에서도 IP를 가지고 있는데 왜 굳이 Service를 이용해 Pod에 접근할까 ?
왜냐하면 Pod는 쿠버네티스에서 시스템 장애, 성능 장애 등으로 언제든지 죽을 수 있고 언제든지 재생성 된다면 IP의 주소가 바뀌므로 신뢰성이 떨어진다. 하지만 Service는 사용자가 지우지 않는 한 서비스는 신뢰성을 보장한다.

1. type: ClusterIP

• 클러스터 내에서만 접근이 가능(Pod의 IP와 동일함)

  • 즉, 모든 오브젝트들이 접근 가능하다.
  • 외부에서는 접근이 불가능하다.
• 여러 개의 파드들을 연결시켜 줄 수 있고, 트래픽을 분산해서 보내준다.
• Service의 default 값은 ClusterIP이다.

1-1. 언제 사용해야 할까 ?

클러스터에 내에서만 사용하는 서비스.
즉, 외부에서 접근할 수 없기 때문에 인가된 사용자(운영자)가 사용할 수 있다.
또한 주된 작업 내용은 내부 대쉬보드, Pod 서비스 상태 디버깅

2. type: NodePort

기본적으로 ClusterIP 타입과 같은 기능이 포함되어 있음

이 타입의 가장 큰 특징은 모든 노드에 Port를 할당해 준다.
또한 외부로부터 어느 특정 노드의 IP에 대한 요청이 오던 간에 IP+NodePort를 입력해 준다면 서비스에 연결된 각 Pod에 접근이 가능하다.

• 노드 포드 범위는 30000~32767

추가 설명: 어떤 노드한테 온 트래픽이든 상관없이 Service(자신)한테 연결되어 있는 파드들한테 트래픽 분산을 해준다.

하지만 externalTrafficPolicy 옵션을 사용하면 특정 노드한테만 즉, 특정 노드의 IP를 통해 트래픽을 설정 할 수도 있다.

2-1. 언제 사용해야 할까 ?

• 내부망 연결용으로 쓰인다.(호스트 아이피(Node)는 보안적으로 내부망에서만 접근 가능하게 구성해하기 때문에)
• 데모 또는 일시적인 외부 연동용으로 쓰인다.

3. type: LoadBalancer

기본적으로 NodePort 타입과 같은 기능이 포함되어 있음 추가적으로 LoadBalancer는 각각의 Node에 트래픽을 분산하는 역할을 한다.
기본적으로 쿠버네티스를 운영한다면 외부 접속 IP주소는 기본적으로 생기지 않는다. 별도로 외부 접속 IP를 할당해 주는 플러그인이 설치되어 있어야 한다.

GCP, AWS, Azure, OpenStack 등은 자동으로 플러그인이 설치되어 있어 LoadBalancer 타입의 Service 생성 시 외부 접속 IP주소를 자동으로 할당해 준다.

3-1. 언제 사용해야 할까 ?

외부에 시스템 노출용

내부 IP를 노출 시키지 않고, 외부 IP만 노출시킴

Volume

1. emptyDir

파드 안에 생성되며, 컨테이너들끼리 데이터를 공유하기위해 사용한다.

• 최초에 사용할 때는 항상 Volume 내용이 비어있기떄문에 명칭이 정해짐
• 마운트가 된 Volume에 저장함. 즉, 해당 Volume에 저장 시키면 컨테이너들끼리 서로 데이터 공유가 가능하다.
• 파드 생성시 만들어지고 삭제시 없어지기 때문에 꼭 일시적인 사용목적에만 사용
• 옵션 Volume의 name 설정이 같다면, 서로 다른 컨테이너들끼리 마운트의 경로가 달라도 공유가 가능

2. hostPath

Pod가 올라가 있는 Node의 Volume를 사용한다.

• emptyDir과의 차이점은 각각의 Pod들이 Node Path를 마운트해서 공유하기 때문에, 이 데이터는 Pod들이 종료되었어도 보존됨. 단, Pod가 재생성될 때 다른 Node로 배치될 수 있기 때문에 기존의 데이터를 못쓸 가능성도 있음

  새로운 Node를 추가할 때마다 기존의 volume를 마운트해서 연결시켜줄 수 있지만 비추한다.
  (사람의 개입으로 설정 => 실수 발생 가능성) == 자동화에 안좋다.

각각의 Node들의 설정 파일들을 Pod 자신이 할당되어 있는 Node(호스트)에 데이터를 읽거나 써야할 때 사용한다. 즉, 파드에 있는 데이터를 저장하기 위한 용도가 아닌, 노드에 있는 데이터를 파드가 사용하기 위한 목적이다.

주의사항 : Pod 생성 전에 지정한 Node - Volume의 경로가 존재 해야한다.

3. PVC(Persistent Volume Claim) / PV(Persistent Volume)

Pod의 영속성 있는 Volume을 제공하기 위한 개념이다.
실제로 로컬 Volume 즉, Node의 볼륨 외에 외부의 Volume 서비스(AWS, git 등)와 연동해서 사용할 때도 많다.
그리고 외부의 Volume 서비스들을 연동하기 위한 설정 사항은 다르다. 즉, 각각의 분리가 필요하다.
따라서 Admin이 정의해 놓은 각각의 PV와 User가 정의해 놓은 각각의 PVC가 매핑 되는 것만 연결해서 사용하면 목적에 맞는 Volume를 연동해 사용할 수 있다.

PV - Spec .yml 파일 안에 정의 된 capacity 속성과 accessModes속성으로 매핑을 한다.

3-1. 프로세스

1. PV 정의 생성
2. PVC 생성
3. 쿠버네티스가 PVC를 이용해 자동으로 PV에 연결(Spec의 내용을 보고 쿠버네티스가 알아서 할당한다.)

4. Pod 생성 시 PVC에 마운팅이 되면서 전체적인 시스템 구조는 이러한 형식을 갖는다.

   Pod - PVC - PV - 외부 서비스

참고 사이트

https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/

위로 올라가기💨